Everything you 
always wanted to 
know about HPFS... 


...but were afraid to ask. By Max and Sandy Eidswick 


Y ou've probably seen many articles about the High 
Performance File System (HPFS) and plenty of 
coverage in OS/2-related books. So why yet 
another one? Because, more often than not, the 
articles written about HPFS delve so deeply into the file sys- 
tem's data structures, Fnodes, and bitmaps, that HPFS's basic 
benefits are overlooked — a case of not being able to see the 
forest for the trees. 

Let's look at the forest by discussing a few of the most com- 
mon questions about HPFS. 

Where did HPFS originate? 

Back in 1985, IBM and Microsoft agreed to jointly define and 
ship Operating System 2, the next generation of DOS. OS/2 
development continued during the mid-to-late 1980s as a 
cooperative effort involving design engineers, developers, and 
programmers from both companies. 

Part of this cooperative development was the design of a' 
new, advanced file system. Network servers needed a file sys- 
tem better suited to efficiently managing huge amounts of data 
on large disks than DOS's File Allocation Table (FAT) system. 
They needed a file system that was both reliable and capable of 
supporting the multitasking server environment. 

HPFS provided the solution. It was designed by Gordon 
Letwin of Microsoft's network division as an advanced file sys- 
tem for Microsoft's LAN Server product. (This original version 
of HPFS is what we know today as HPFS386.) 

When OS/2 1.2 shipped, it included its own desktop ver- 
sion of HPFS, providing the desktop with a file system that 
could manage large volumes of disk space more efficiently 
than the FAT system and robust enough to support OS/2's mul- 
titasking ability on the standalone PC. 

The original HPFS386 was written in assembler language. 
The newer HPFS, shipped with all versions of OS/2 since 1 .2, is 
written instead in C, most likely because C was more comfort- 
able for those maintaining code than was assembler language. 

How does HPFS differ from FAT? 

The key difference between HPFS and FAT is the way each goes 
about storing data on a disk. To understand the difference, let's 
first explore how storage space is allocated on a disk formatted 
under FAT. 


FAT 

FAT is short for file allocation table. The file allocation table is 
just that: a table containing entries that point to the physical 
location on the disk of the cluster or clusters in which all or 
part of a file is stored. A cluster is a grouping of 512-byte disk 
sectors (typically the smallest element of disk storage addressed 
by PC-based device drivers). Files are simply chains (or linked 
lists) of clusters in the file allocation table. The clusters con- 
taining the sectors of any given file are, more often than not, 
scattered over the disk. 

What is most important to understand about the file allo- 
cation table is that its size is limited to no more than 64K 
entries. Therefore, as disks have gotten larger, the size of the 
minimum cluster has had to increase, too, in order to keep the 
number of table entries below the 64K threshold. Table 1 
shows the relationship between the size of a disk or volume 
and the minimum cluster size permissible using the file allo- 
cation table. 

Every file on your disk consists of at least one cluster. As the 
size of a file exceeds one cluster, a new cluster is allocated and 
added to the end of the chain. For each file, an average of half 
the last cluster will be unused. This unused space is known as 
slack or lost space, and as your disk size grows, the proportion 
of it that is consumed by slack space grows dramatically, 
because of the ever-increasing size of the minimum cluster. 

To examine the relationship between disk or volume size 


Table 1: File allocation table 
relationship between disk or volume 
size and minimum cluster size. 


Disk or Volume Size 

32 MB 
64 MB 
128 MB 
256 MB 
512MB 

1 GB 

2 GB 
4 GB 


Minimum Cluster Size 

'/^KB (512 bytes) 

1 KB 

2 KB 
4 KB 
8 KB 
16 KB 
32 KB 
64 KB 
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and lost space, we 
looked at several of 
the machines in our 
office in terms of the 
drive's size and the 
number of files it 
contained. We use 
them here as an 
example. While a 
mix of files in other 
settings will vary 
from machine to 
machine, the gener- 
al concept we pre- 
sent here with re- 
gard to lost space 
seems to hold true across the board. 
That is: As the size of the volume dou- 
bles so does the percentage of total disk 
space lost. 

Table 2 shows the slack space wasted 
as disk volumes grow larger. It's based on 
the assumption that a typical 512MB 
volume will contain about 20,000 files. 
A volume half that size (256MB) should 
hold about 10,000 files; one double in 
size (1GB) should hold twice as many. 
See how the slack space dramatically 
increases as drives increase in size — your 
new 1GB disk drive is not able to hold 
twice the number of files that your old 
512MB disk did. Why don't you get 
twice the storage? Because of the ineffi- 
ciencies of the FAT file system. 

The FAT file system provided an 
excellent solution for the limited needs 
of the early DOS and Windows applica- 
tions. After all, in the early 1980s, the 
primary storage media was limited in 
size itself. First, there was the 180KB 
floppy, then came the 360KB floppy. Fi- 
nally, we saw the 80286-class machines 
with 1.2MB floppies and huge 10MB 
hard-disk drives. Today, most applica- 
tions will take at least 20MB of disk stor- 
age each, and the operating system may 
take more than 40MB for system files. 

As PC technologies have progressed 
to provide faster processors, bigger appli- 
cations, and larger hard disks, the limi- 
tations and inefficiencies of FAT-based 
file access begin to impinge on both the 
user and the operating system. Today, it 
is common to find ordinary desktop PCs 
purchased with 1GB to 2GB hard disks. 

HPFS 

Armed with an understanding of the 
mechanics of the file allocation table, it's 
time to look at how HPFS differs in its 
approach to storing data on your disk. 


MB 1,250 314 KB 

1KB 2,500 1.25 MB 

2 KB 5,000 5 MB 

4 KB 10,000 20 MB 

8 KB 20,000 80 MB 

16 KB 40,000 320 MB 

32 KB 80,000 1.28 GB 


The key is that the basic storage alloca- 
tion unit is no longer a cluster. Instead, 
HPFS stores data using 512-byte sector 
boundaries — regardless of the disk's size. 

To realize the impact this has on a 
disk, you need only compare two like- 
size volumes, one FAT and the other 
HPFS. For example, on a 128MB FAT-for- 
matted volume with a 2K cluster, you 
need 2,048 bytes (one cluster) to store a 
file that is only 1,024 bytes long. When 
the same volume is formatted using 
HPFS, you need two 512-byte sectors or 
a total of only 1,024 bytes to store the 
same file. 

HPFS Versions 

T he HPFS version describes the level of 
HPFS used to format the volume and 
has no correlation to the OS/2 version. The 
versions in use currently are 2.2 for small 
HPFS volumes, 2.3 for large HPFS volumes, 
and 2.4 for HPFS386 volumes. 

In general, the hpfs.ifsani corresponding 
uhpfs.dll (in which the HPFS utilities FOR- 
MAT and CHKDSK are kept) are not depen- 
dent upon the operating system release. 
Normally, however, you want to run the ver- 
sions that came with the retail version of 
OS/2 running on your system. 

From time to time (between retail ver- 
sions of OS/2), IBM releases FixPaks that 
correct a variety of very specific user-reported 
problems. They are quick fixes that not every- 
one needs or should apply. While the FixPaks 
should not break anything, it's always possi- 
ble. Therefore, we recommend that you keep 
backup copies of your original hpfs.ifs and 
uhpfs.dll, so that you will have them should 
you need them. 


1 % 

2 % 

4% 

8 % 

16% 

32% 

64% 


Table 3 takes this example one step 
further by looking at what the impact 
will be of storing this same 1KB file on 
larger volumes with larger cluster sizes. 
Imagine the toll that downloading 
thousands of small message files (typi- 
cally 256 to 1,024 bytes in size) has on 
a 1GB FAT-formatted volume, where 
15Kbytes of space are lost for every 
1Kbyte used. 

How does HPFS 
resist fragmentation? 

HPFS resists the tendency toward disk 
fragmentation, which is a part and par- 
cel of a FAT-formatted drive, by virtue of 
the way that data storage is allocated on 
an HPFS volume. First, while the small- 
est storage allocation unit on a FAT-for- 
matted drive is a 512-byte cluster, this is 
only the case when the volume is less 
than 32MB in size. By contrast, the only 
storage allocation unit on an HPFS-for- 
matted drive is a 512-byte sector, regard- 
less of the size of the drive. 

Next, HPFS divides each volume into 
bands of 8MB — again, regardless of the 
size of the volume. Unlike the file allo- 
cation table with its fixed number of 
entries, HPFS creates as many 8MB 
bands as necessary to fill up the volume. 
Each band has its own free-space 
bitmap, with HPFS keeping statistics on 
each band. These statistics are used to 
select the most favorable bands for allo- 
cating space to a specific file. 

Finally, HPFS attempts to keep a file's 
allocation localized and contiguous. 
Whenever possible, the file system pre- 
allocates additional contiguous space for 
a file to grow into, rather than having to 
store the file in a new location. 
Fragmentation is minimized by allocat- 
ing files from separate data bands and 
preallocating contiguous file space. 


Table 2: Slack space in various sized disk volumes under the FAT 
system. 


Volume Size Cluster Size Avg. No. of Files Estimated Slack Space 

32 MB 
64 MB 
128 MB 
256 MB 
512 MB 

1 GB 

2 GB 


Slack Space as % 
of Total Space 
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Volume Size 

Minimum FAT Cluster Size 

128 MB 

2 K 

256 MB 

4k 

512MB 

8 K 

1 GB 

16 K 


Why can’t I access a 
drive that hasn’t been 
correctly stopped? 

Each time you correctly shut down your 
system, the file system is shut down, its 
buffers are flushed, and the "dirty read" 
flag on each HPFS partition is reset to 
"clean.” 

An HPFS drive that hasn't been shut 
down correctly can't be accessed because 
the file system sees the "dirty read" flag. 
The flag signals the file system that the 
drive was stopped before its free-space 
bitmaps could be updated to reflect 
changes to the drive's contents. To pre- 
vent damage caused by using those po- 
tentially inaccurate bitmaps, the file sys- 
tem requires that the drive be checked 
(using CHKDSK, the HPFS disk-check- 
ing utility) before any of the data on the 
drive is accessed. CHKDSK corrects any 
flaws and then releases the lock. 

Sometimes you may need to run 
CHKDSK more than once. That's be- 
cause on an HPFS drive, the primary and 
secondary disk structures are checked 
and "cleaned up" in multiple passes of 
the CHKDSK program. Therefore, if 
there are errors on a drive, a single pass 
may not be enough. The program 
should be mn again and again until no 
errors (or corrections) are reported. 

Why aren’t there 
any HPFS floppies? 

We can fall back on definitions, accord- 
ing to IBM's Doug Azzarito. Because the 
HPFS specification says in writing that 
HPFS does not support removable 
media, you can't have HPFS-formatted 
floppies! It's not a case of its being tech- 
nically impossible (after all, you could 
trick OS/2 into thinking that a floppy 
disk is not a removable disk) — it just 
doesn't make sense. 

The more logical reason that no 
HPFS-formatted floppies exist is because 
of the file system's use of the lazy-write 
cache. In order to improve system per- 
formance, data is held in memory cache 


1 k 

1 k 

lk 

CO 

Ik 

7k 

1 k 

15k 


buffers and written to disk when the disk 
is idle. If the target media is removed 
before the file system writes the cached 
data to disk, the data is lost. 

However, the data held in the cache 
buffers is not lost if, prior to removing 
the media, HPFS is notified. The media 
itself must do this by providing a signal 
for HPFS that causes the file system to 

WhatisHPFS386? 

M istoricaily specking, HPFS386 is the 
original High Performance File 
System, designed by Gordon Letwin of 
Microsoft. It was intended to be used exclu- 
sively with the Microsoft LAN Server product 
and was written in assembler language. 

HPFS386 uses special, undocumented 
interfaces to and from the LAN Server code. 
These speed up disk I/O (input/oufput) by 
allowing I/O requests to go directly from the 
file system to the network adapter. The result 
is disk I/O with less overhead and speedier 
response to network client requests for disk 
access. 

Today, HPFS386 is available with IBM's 
Advanced LAN Server product. While it is com- 
patible with HPFS, it also includes the follow- 
ing features specifically designed for LAN use: 

■ Access Control Lists (ACLs) — to allow user 
permissions to be set on a file-by-file basis: 

■ DASD Limits — to allow the LAN adminis- 
trator to control the use of free disk space 
on a per-user basis 

■ Separate Control Program — to allocate 
cache for the file system and allow cache 
parameters to be set independently for 
each volume. 

Because most desktop PCs running OS/2 
Warp aren't Advanced LAN Servers, and, 
therefore, would not stand to benefit from the 
additional network features included in 
HPFS386, there is no reason for them to run 
HPFS386 instead of standard HPFS. 


issue a com- 
mand to "re- 
determine" 
the media. 
This com- 
mand tells 
HPFS to read 
the floppy's 
boot sector 
before each 
write. Unfor- 
tunately, the constant monitoring of the 
floppy's boot sector makes using an 
HPFS-formatted floppy more painful 
than beneficial. 

Newer, more sophisticated remov- 
able media is capable of notifying the 
file system of changes in media and 
avoiding the necessity for the file sys- 
tem to constantly monitor the media's 
boot sector; someday, they may be 
HPFS formatted. 

Why is there a limit 
on HPFS cache size? 

HPFS is an OS/2 installable file system. 
This IFS mechanism defines the inter- 
face between the operating system and 
the file system. One interface is the 
memory allocation available to the IFS. 
The memory available for use by the IFS 
is limited by the OS/2 kernel and is cur- 
rently fixed at 2MB. To increase the 
HPFS cache size, either the OS/2 kernel 
will have to remove the limitations, or a 
non-IFS program will have to allocate 
memory for HPFS. 

HPFS is based upon a 16-bit memory 
model (remember, all physical device 
drivers in the OS/2 world are 16-bit). 
Memory cache blocks are allocated dur- 
ing initialization of the IFS as OS/2 
boots, based upon the cache size speci- 
fied on the IFS's command line in your 
config.sys file. 

HPFS uses cache memory as 2K 
cache blocks — thus a 2MB cache 
(/CACHE.-2048) contains 1,024 cache 
blocks. Each cache block must have a 
corresponding BuffNode (a cache block 
pointer). Because HPFS is a 16-bit im- 
plementation, its global data segment 
(limited to 64K bytes) can only hold so 
many cache block pointers. For exam- 
ple, 1,024 cache blocks at 59 bytes per 
cache pointer gobbles up 59K of the 
64K global data segment. 

How should you set the 
HPFS cache parameters? 

One of the most powerful features 


Table 3: Comparing slack space for 1KB file stores under both FAT and HPFS. 


Actual File Size Lost Space on a FAT Volume Lost Space on 

HPFS Volume 

None 
None 
None 
None 
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Table 4: Guidelines for setting cache parameters for systems running OS/2 2.x or later. 


HPFS Partitions Only 


RAM 

Cache 

Lazy Writes 

MaxAge 

Diskldle - 

Bufferldle 

Other 

16MB 

2048 

/lazyron 

40000 

30000 

20000 

REM out the DISKCACHE statement 

12MB 

1536 

/lazy:on 

40000 

30000 

20000 

■ REM out the DISKCACHE statement 

8MB 

1024 

/lazyion 

40000 

30000 

20000 

REM out the DISKCACHE statement 





FAT Partitions Only 



RAM 

Disk 

Lazy Writes 

MaxAge 

Diskldle 

Bufferldle 

Other 


Cache 






16MB 

2048 

AW 

N/A 

N/A 

N/A 

REM out IFS=HPFS.IFS statement 

12MB 

1536 

/LW 

N/A 

N/A 

N/A 

REM out IFS=HPFS.IFS statement 

8MB 

1024 

/LW 

N/A 

N/A 

N/A 

REM out IFS=HPFS.IFS statement 




HPFS & FAT Partitions with HPFS Active 


RAM 

Cache 

Lazy Writes 

MaxAge 

Diskldle 

Bufferldle 

Range for DiskCache Value 

16MB 

2048 

/lazyion 

40000 

30000 

20000 

512-1024 

12MB 

1536 

/lazyion 

40000 

30000 

20000 

256 -512 

8MB 

1024 

/lazyion 

40000 

30000 

20000 

128-256 




HPFS &FAT Partitions with FAT Active 


RAM 

Cache 

Lazy Writes 

MaxAge 

Diskldle 

Bufferldle 

DiskCache 

16MB 

1024 

/lazyion 

40000 

30000 

20000 

2048 

12MB 

768 

/lazyion 

40000 

30000 

20000 

1536 

8MB 

512 

/lazyion 

40000 

30000 

20000 

1024 


available in the High Performance File 
System is the optional cache-tuning 
parameters for lazy writes — that is, 
postponing writing data to the hard 
disk for a short period of time to maxi- 
mize the applications' performance. 
These can significantly enhance system 
performance. 

The FAT cache only allows you to 
turn lazy writes on or off. The HPFS 
cache lets you also adjust the settings for 
MaxAge, Diskldle, and Bufferldle on- 
the-fly, using the CACHE command fol- 
lowed by the appropriate parameter: 

MaxAge — Elapsed time (in millisec- 
onds) that can expire since the last 
write to your physical disk occurred, 
regardless of how many times the 
data held in the HPFS cache buffers 
may have been updated. 

Diskldle — Elapsed time (in millisec- 
onds) that the disk controller can be 
inactive before the lazy writer will 
write data held in HPFS cache buffers 
to your physical disk, regardless of 
the MaxAge and Bufferldle settings. 
Bufferldle — Elapsed time (in millisec- 
onds) before the lazy writer writes the 


data held in HPFS cache buffers to 
your physical disk. 

We recommend that the number of 
milliseconds specified for MaxAge be 
greater than that specified for Diskldle, 
and, that the number of milliseconds 
specified for Diskldle be greater than 
that specified for Bufferldle. There are 
no "correct" settings that are applicable 
for every system. They vary depending 
upon the type and volume of disk I/O 
on a system. 

The guidelines in Table 4, for setting 
cache parameters, apply to any system 
running OS/2 2.x through OS/2 Warp. 
To determine which settings would be 
best for your system, select the appro- 
priate section of Table 4: Make your 
choice based on whether your system is 
formatted as HPFS-only or FAT-only, or 
using both with either HPFS or FAT 
"active." 

For our purposes, active and passive 
are descriptors of the way a partition is 
used. If it is seldom used, consider it 
passive. If a lot of disk-intensive I/O 
occurs on the partition, consider it 
active. Because swapper I/O does not 


pass through the normal system cache, 
it does not have any bearing on 
whether you should consider a drive 
active. 

Remember, the right setting for your 
particular system will depend upon the 
type of applications you are running and 
the amount of RAM in your computer 
system. However, the higher the values 
are for the MaxAge, Diskldle, and 
Bufferldle parameters, the more lati- 
tude the lazy-writer will have as it prior- 
itizes requests. 

Finally, based upon the file system 
and cache-tuning testing we did in con- 
junction with developing DCF/2, we dis- 
covered the following to be true: 

■ HPFS actually requires 128 to 130Kof 
committed memory, as opposed to 
the widely perceived 512K. As cache 
size increases to 2MB, this require- 
ment increases as well, up to a maxi- 
mum of about 240K. 

■ The optimal cache size seems to be 
1,536. 

■ When comparing the relative merits 
of HPFS versus FAT: On partitions of 
identical size, HPFS gives you about 
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Other HPFS Benefits 

T he High Performance File System was designed specifically to address key issues such as lost 
storage. But HPFS offers more than better handling of slack space. Other advanced features 
that make HPFS a superior file system are: integrated Extended Attributes, multithreaded I/O, and 
strategic allocation of directories. 

Integrated Extended Attributes 

Extended Attributes contain information about a file. File attributes on a FAT volume are limited 
to simple read-only, system, hidden, and archive flags. File attributes on an HPFS volume are called 
Extended Attributes (EAs) because they provide not only these basic flags but also allow for highly 
generalized file information (similar to environment variables) to be kept with the file. 

We feel that the single most important feature of HPFS is the way it integrates a file's Extended 
Attributes with the file itself rather than placing them in a separate file. For example, on a FAT-for- 
matted volume, a file's EAs are stored in an external file, EA_DATA._SF; on our 450MB FAT-for- 
matted volume, that EA_DATA._SF file is a 5MB file — scattered all over the volume. 

By contrast, on an HPFS-formatted volume, file-related information is stored directly within the 
file's basic disk structure. Space permitting, the file's EAs are contained directly in a file or file direc- 
tory's Fnode. Otherwise, EAs are kept in normal disk sector storage in runs pointed to by the Fnode 
allocation data structures. 

Why are integrated EAs so important? Because an advanced operating system like OS/2 uses EAs 
to maintain key information about certain files. In particular, many of the operating system compo- 
nents require specific extended attributes — on a FAT-formatted boot disk, where these EAs are con- 
tained externally in the EA_DATA._SF file, the EAs may become cross-linked. Unfortunately, the pre- 
scription for recovery usually calls for a complete reinstall of the operating system. Because extend- 
ed attributes on an HPFS-formatted volume are integrated, they cannot be inadvertently cross-linked. 

Multithreaded I/O 

The benefit of HPFS's multithreaded I/O is improved system performance. Multiple operations 
happen concurrently, in the background, or when the disk controller is idle. Disk I/O is distributed 
evenly and the processor used more efficiently. 

HPFS uses caching extensively. Caching involves allowing data being written to disk to actual- 
ly be written to high "memory cache blocks," which are then later "lazy-written" to physical disk 
storage. 



FAT design is based upon a linear table of entries that must be searched from the beginning when 
a file or directory is requested. By contrast, HPFS places key directory and file information near the 
seek-center of the drive and employs a highly efficient, binary tree mechanism in search operations. 
The result is vastly reduced disk head movements and search times, especially on large volumes. 

In addition, built into the HPFS implementation is special file and directory name caching, known 
as the "look-aside" naming cache. Each directory and file name in the cache is represented by a 
check-sum (a single 32-bit value). When the cache is searched for a particular directory or file name, 
the search requires only one single, 32-bit compare, as opposed to comparing every byte, byte-by- 
byte, of a potentially very long file name, in order to determine if it is target directory or file. This 
makes searches of HPFS volumes faster and more efficient. 


15% more space, and performance is 
about 28% better. 

■ Instead of continuing to increase per- 
formance, a DISKCACHE value in 
excess of 2,048 seems to degrade per- 
formance rather than improve it. 

Do any other operating 

systems use HPFS? 

What about NTFS? 

Microsoft's Windows NT supports HPFS. 

There are also third-party developers 


who have created HPFS-compatible dri- 
vers for DOS, Linux (a new version of the 
UNIX operating system), and other 
operating systems. Users of Windows 
NT probably use a similarly named file 
system, NTFS, the New Technology File 
System, rather than HPFS. 

HPFS obviously predates Windows 
NT and its NTFS. Both share a common 
goal: They are designed to compensate 
for the inadequacies of the file allocation 
table in light of today's multigigabyte 


disks and multitasking operating envi- 
ronments. They provide improved per- 
formance on large volumes, more effi- 
cient data storage, and greater reliability 
than the FAT file system. 

According to Microsoft's Gary 
Kimura, co-architect and developer of 
NTFS, several significant differences 
exist between NTFS and HPFS. First and 
foremost is that NTFS is truly a 64-bit file 
system capable of supporting almost 
infinitely large files. Another major dif- 
ference is that NTFS is a recoverable file 
system — NTFS journals disk transactions 
so completely that CHKDSK is unneces- 
sary. On the other hand, NTFS takes 
after the FAT system in that it doesn't 
always store data at 512-byte sector gran- 
ularity; NTFS uses a cluster-like storage 
unit, which grows in size as the size of 
the volume grows. 

Another factor in "comparing" Win- 
dows NT's NTFS with OS/2's HPFS is that 
Microsoft has incorporated an extreme- 
ly efficient file-by-file compression sub- 
system into NTFS. IBM has not elected 
to provide compression with HPFS. 

When should and 
shouldn’t I use HPFS? 

Some people insist that you should 
always use HPFS. Others caution that if 
backward compatibility with DOS is an 
issue, you may find a mixture of FAT and 
HPFS better suited to your needs. 

If you use large databases, HPFS is 
preferable to FAT. Databases are usually 
large, randomly stored files. FAT is not 
well-suited to perform searches on such 
files as efficiently as is HPFS. 

Is your system likely to crash on a reg- 
ular basis, perhaps because you're devel- 
oping and testing systems-level soft- 
ware? Our own experience in develop- 
ing device drivers — and the improper 
shutdowns that are inherently a part of 
device driver development — leads us to 
suggest that a FAT-formatted volume is 
preferable in such a setting. The time 
HPFS needs to check an improperly 
stopped HPFS-formatted drive offsets 
any perceived performance benefits. In 
this case, you would find that you can 
get back to work faster if your system is 
FAT formatted rather than HPFS. 

As a developer, is there 
anything I should consider 
when dealing with HPFS? 

Opinion on this issue seems divided, 
too. One HPFS developer at IBM said 
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no, while another suggested that there 
are parameters that developers should 
take into account: NEWNAME and 
FILESIZE. 

The NEWNAME parameter allows 
OS/2 to identify a program as compati- 
ble with HPFS support for long file 
names. This parameter is used when 
linking the program. The FILESIZE 
parameter helps minimize fragmenta- 
tion of the data stored on an HPFS-for- 
matted volume. If the FILESIZE para- 
meter is set (when the DosOpen func- 
tion is used to create a file) to whatever 
size the developer anticipates the file will 
have when closed, then HPFS knows 
how much space to allocate for the file 
and does so accordingly. 

Conclusion 

The High Performance File System is 
designed to address the needs of today's 
OS/2 user. It is capable of managing vast 
amounts of data on large volumes in a 
multitasking environment far more effi- 
ciently than FAT, in part due to: 

■ Storage allocation, based upon 512- 

byte sector boundaries, regardless of 


volume size that minimizes the por- 
tion of your disk lost to slack space. 

■ Multithreaded design, extensive use 
of sophisticated caching techniques, 
and the lazy writer, which allow the 
file system to provide significantly 
enhanced system performance. 

■ Strategic allocation directories and 
files that allow HPFS to perform com- 
plex search operations with minimal 
disk head movement and greater 
efficiency than FAT. 

■ Design and data structures that allow 
it to allocate and preallocate contigu- 
ous file space, minimizing the disk's 
tendency to become fragmented. 

■ Support of long file names of up to 
255 characters, which provides far 
greater file- and directory-naming 
flexibility than does the traditional 
eight-dot-three DOS convention. 

■ Integrated extended attributes for 
both the operating system and appli- 
cations within its own data structures 
that increase the system’s robustness 
and reliability. 

■ Volume integrity and data reliability 
that are managed while a volume is 
in use. 


While DOS and its FAT file system 
have served users well, neither was ever 
intended for use on today's super-fast 
PCs with multigigabyte hard disks. 
Operating systems of the 1990s, like 
OS/2 Warp, demand a file system that 
can offer the features HPFS provides 
today. 
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